home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940272.txt < prev    next >
Internet Message Format  |  1994-11-13  |  22KB

  1. Date: Mon, 15 Aug 94 04:30:17 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #272
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Mon, 15 Aug 94       Volume 94 : Issue  272
  11.  
  12. Today's Topics:
  13.                             Help with info
  14.                  Need mods to do FSK on Alinco DR-600
  15.                         Packet BBSs for Unix?
  16.                        Packet Node Info Wanted
  17.                   PK-88 to Kenwood TM-231A interface
  18.      simptr21.zip - Generic TNC comm program (packet, rtty, etc)
  19.                        Smallest MultiMode TNC?
  20.                            TAPR FTP SITE???
  21.             Widrow-Hoff LMS algorithm for DSP??? (2 msgs)
  22.             Windows 3.1 and Baycom Modem TCP/IP networking
  23.  
  24. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  25. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  26. Problems you can't solve otherwise to brian@ucsd.edu.
  27.  
  28. Archives of past issues of the Ham-Digital Digest are available 
  29. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  30.  
  31. We trust that readers are intelligent enough to realize that all text
  32. herein consists of personal comments and does not represent the official
  33. policies or positions of any party.  Your mileage may vary.  So there.
  34. ----------------------------------------------------------------------
  35.  
  36. Date: Sat, 13 Aug 1994 17:54:00 GMT
  37. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!iat.holonet.net!bthouse!mike.grose@network.ucsd.edu
  38. Subject: Help with info
  39. To: ham-digital@ucsd.edu
  40.  
  41. MS>From: mike@jakesys.sol.net (Mike Sheridan)
  42.   >Newsgroups: rec.radio.amateur.digital.misc
  43.   >Subject: Help with info
  44.   >Date: Sat, 6 Aug 1994 06:54:32 GMT
  45.   >Message-ID: <1994Aug6.065432.1392@jakesys.sol.net>
  46.   >Organization: jakesys - Public Access UNIX - Manitowoc, WI
  47.  
  48. MS>Can anyone steer me into info on how to get started with packet radio
  49.   >with a 486 clone?
  50.   >---
  51.  
  52.    Hello Mike.  You have the main thing needed for packet radio.  Just
  53.    get you a tnc(terminal node controller) and a two meter radio. a
  54.    Handy talkie works well, or you can use a mobile rig.  Most use HT's
  55.    because they are less expensive used.  You need to get software for
  56.    packet.  If you use Procom, it will work very good.  You just set it
  57.    up in the dumb terminal mode.  Then get the manual out for your tnc,
  58.    and start programing the commands you will need for packet.  There
  59.    are many programs out there, but I would suggest using a dumb
  60.    terminal for a while to learn the commands and kind of get familiar
  61.    with it.  I use a Tandy 486 machine, and it works very well.  You
  62.    don't have to have too much to run packet,  as it doesn't take much
  63.    memory to run it. If you have anymore questions, please let me
  64.    know.  Cul....Mike, KE4CLE
  65.  
  66.  
  67.  * QMPro 1.50 42-2694 * All rising to a great place is by a winding stair.
  68.  
  69. ------------------------------
  70.  
  71. Date: 13 Aug 94 08:00:00 GMT
  72. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!wa4mei!totrbbs!steve.diggs@network.ucsd.edu
  73. Subject: Need mods to do FSK on Alinco DR-600
  74. To: ham-digital@ucsd.edu
  75.  
  76. Hi Rob,
  77.  
  78. ftp to oak.oakland.edu and look in /pub/hamradio/mods/alinco. If it
  79. isn't there message back to me and I'll look in my my mod file
  80. collection.
  81.  
  82. Regards,
  83. Steve Diggs
  84.  
  85. ----
  86. Top Of The Rock BBS - Lilburn, GA         SYSOP: Steve Diggs
  87. UUCP: totrbbs.atl.ga.us               Snailmail: 4181 Wash Lee Ct.
  88. Phone: +1 404 921 8687                           Lilburn, GA 30247-7407
  89.  
  90. ------------------------------
  91.  
  92. Date: Fri, 12 Aug 1994 03:00:27 GMT
  93. From: ihnp4.ucsd.edu!usc!cs.utexas.edu!convex!news.duke.edu!eff!news.kei.com!ssd.intel.com!chnews!ornews.intel.com!ibeam!knauer@network.ucsd.edu
  94. Subject: Packet BBSs for Unix?
  95. To: ham-digital@ucsd.edu
  96.  
  97. Greetings all.
  98.  
  99.     I'm relatively new to the packet scene, so if this is an obvious question,
  100. please forgive.
  101.  
  102.     What I'd like to find is code for a packet BBS that will work on a Unix
  103. box (specifically, SunOS on a Sun 3/60).  Provision for either BBS operation
  104. or direct login (sort of a packet getty) would be fine; from that point I
  105. could hack the source either way.
  106.  
  107.     Does such a creature exist?  If not, do any of the common BBSs for the
  108. PC (W0RLI, etc.) come with source?  I'd like to avoid starting from scratch
  109. if at all possible.
  110.  
  111. [The next obvious question is if there already exists a packet->UUCP
  112. gateway, but I'll save that for when I have spent more time goofing around
  113. with packet in general...]
  114.  
  115. Thanks,
  116. Rob
  117. --
  118. Rob Knauerhase [knauer@ibeam.intel.com]  Intel Mobile & Home Architecture Lab
  119.   "Always listen to experts.  They'll tell you what can't be done, and why.
  120.    Then do it."   -- Robert Heinlein (Lazarus Long)
  121.  
  122. ------------------------------
  123.  
  124. Date: Thu, 11 Aug 1994 14:40:25 GMT
  125. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!jsissom.dmed.iupui.edu!JAY@network.ucsd.edu
  126. Subject: Packet Node Info Wanted
  127. To: ham-digital@ucsd.edu
  128.  
  129. Interesting, an Amateur Radio mode where DXing is discouraged!  This is a new 
  130. one. . .
  131.  
  132. I agree that people should use their closest BBS, but there shouldn't be any 
  133. problems with people node hopping to see how far they can get!  Experimenting 
  134. is what ham radio is all about, isn't it?
  135.  
  136. Jay
  137.  
  138. >::Arrrgh! You're a digi Dxer, the bane of network existance. :-);
  139. >::
  140. >:;Really, we've spent a lot of time educating our users to stay on
  141. >:;their LAN and let the network do the forwarding. All it takes is
  142. >::a couple of digi Dxers accessing a distant BBS to bring a 1200 baud
  143. >:;trunk to it's knees from retries and collisions.
  144.  
  145. ------------------------------
  146.  
  147. Date: Thu, 11 Aug 1994 14:44:42 GMT
  148. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!jsissom.dmed.iupui.edu!JAY@network.ucsd.edu
  149. Subject: PK-88 to Kenwood TM-231A interface
  150. To: ham-digital@ucsd.edu
  151.  
  152. Last night, I built a cable to connect my PK-88 to my TM-231A.  I don't have 
  153. the pin out here, but it was quite simple.
  154.  
  155. Unfortunately, the DCD lite on the PK-88 stays on when the radio is squelched. 
  156. Because of this, the PK-88 will never tell the radio to transmit.  It 
  157. receives fine.  If I am tuned to a repeater and there is no sound coming 
  158. through the repeater, then the DCD lite is off.  I'm kind of confused.  This 
  159. PK-88 has been hooked up to my Icon IC-28H for years with no problems.
  160.  
  161. Has anyone else seen this problem, and solved it?
  162.  
  163. Thanks
  164. Jay
  165. KA9OKT
  166. jay@medicine.dmed.iupui.edu
  167.  
  168. ------------------------------
  169.  
  170. Date: Sun, 14 Aug 1994 14:17:57 GMT
  171. From: ihnp4.ucsd.edu!agate!spool.mu.edu!nigel.msen.com!simtel.coast.net!msdos-ann-request@network.ucsd.edu
  172. Subject: simptr21.zip - Generic TNC comm program (packet, rtty, etc)
  173. To: ham-digital@ucsd.edu
  174.  
  175. I have uploaded to the SimTel Software Repository (available by anonymous
  176. ftp from the primary mirror site OAK.Oakland.Edu and its mirrors):
  177.  
  178. SimTel/msdos/hamradio/
  179. simptr21.zip    Generic TNC comm program (packet, rtty, etc)
  180.  
  181. SimpTerm v2.1 is a simple terminal program designed to be used with
  182. almost any tnc or tu on the market.  Features of SimpTerm are:
  183.  
  184.   o Split window operation.
  185.  
  186.   o Macro key definitions.
  187.  
  188.   o User customizable Help screen
  189.  
  190.   o Most of the non-ascii keys can be used as function keys
  191.  
  192.   o Optional scroll back feature on the receive window and trans-
  193.     mit windows
  194.  
  195.   o Simple status display in the middle of the screen
  196.  
  197.   o Capturing of data to a disk file
  198.  
  199.   o Access DOS commands without dropping communications
  200.     connection
  201.  
  202.   o Control of the com port definitions from command line, init
  203.     file and keyboard.
  204.  
  205.   o Works on 8088 as well as 80486 and everything in-between.
  206.  
  207.   o Status line
  208.  
  209.   o Small enough to work well on resource tight platforms, like
  210.     laptops.
  211.  
  212.   o Selcal functions, limited unattended operation.
  213.  
  214.   o Times can be in GMT or local time.
  215.  
  216.   o A station logging function.
  217.  
  218.   o User selectable color scheme
  219.  
  220.   o Automatic "cq" operation (or any other repetitive transmission
  221.  
  222.   o Function keys and control keys can be assigned to a macro
  223.     string, cause a file to be uploaded or call a function within
  224.     the program.
  225.  
  226. There are loads of programs that are tailored to specific tnc's and
  227. there are dozens of good terminal programs that can control any tnc in a
  228. "dumb" (that's a technical term) manner.  This program is an attempt to
  229. provide the average ham with something in-between.  It has a lot of
  230. features, but not so many as to make use of the program or the tnc
  231. hard.  It requires you to know the commands of your tnc, but also gives
  232. you the flexibility that only direct communications with a tnc can
  233. provide.
  234.  
  235. Jim Lynch, K4GVO
  236. jwl@cray.com
  237.  
  238. ------------------------------
  239.  
  240. Date: Fri, 12 Aug 1994 09:51:32 -0400
  241. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!news.clark.edu!netnews.nwnet.net!raven.alaska.edu!news.acns.nwu.edu!ftpbox!mothost!lmpsbbs!NewsWatcher!user@network.UCSD
  242. Subject: Smallest MultiMode TNC?
  243. To: ham-digital@ucsd.edu
  244.  
  245. In article <newmedia.12.0017040D@teleport.com>, newmedia@teleport.com (Jim
  246. Swenson) wrote:
  247.  
  248. > Please help me find the smallest multi mode TNC available.  I am provisioning 
  249. > a 40' sailboat for a ham friend for a several year cruise. Space is at an 
  250. > absolute premium.  He'll be operating exclusively HF through a modified ICOM 
  251. > M600 SSB marine transceiver. So 300 baud max is fine.  Required modes include 
  252. > Packet, WeFAX, NAVTEX,  RTTY, CW.  PACTOR, G-TOR and SITOR would be cool but 
  253. > not mandatory. Cost is a secondary consideration.   The size of most units
  254. > I've looked at are just not acceptable.  Ideally, we need something about the
  255. > size of a new Supra modem (about 1" h by 5"w by 7" deep).  Is there such
  256. > a beast.  I'd appreciate any help.
  257.  
  258. Although I can't directly answer your query, I'll take the time to point
  259. out something that you must consider: Most commercial/marine HF
  260. transceivers will NOT accept the standard "high" tones 2110/2310 used by
  261. the amateur community due to the required audio rolloffs when operating in
  262. a 2.5 kHz channelized environment.  
  263.  
  264. Check to see if the M600 has a "direct FSK" capability so that you can run
  265. with TTL or RS232 connection to the TNC instead of audio.  That is by far
  266. the preferred method and eliminates problems with AC hum, alternator whine,
  267. or ignition spikes on the interconnecting cables.  If you can't run DFSK,
  268. be ABSOLUTELY sure that the multi-mode unit you purchase offers FSK tones
  269. in the 1200-1800 Hz range or you will have MAJOR problems.  
  270.  
  271. I don't have the CCIR or CCITT list of worldwide standard tones handy, but
  272. I recall 1300/1500 and 1410/1590 both being common.  In any case, you get
  273. the point, especially if your friend's life might depend on this comm gear
  274. at some point.  We all want him back alive, especially if he will be rare
  275. DX during the trip!!
  276.  
  277. -- 
  278. Karl Beckman, P.E.                  <     If our English language is so  >
  279. Motorola LMPS.RNSG.Analog Data      <  precise, why do you drive on the  >
  280. (Square waves & round corners)      <  parkway and park on the driveway? >
  281.    Opinions expressed here do not belong to or represent Motorola Inc.
  282. Amateur radio WA8NVW                        NavyMARS NNN0VBH @ NOGBN.NOASI
  283.  
  284. ------------------------------
  285.  
  286. Date: 14 Aug 1994 13:43:24 GMT
  287. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!noc.near.net!news2.near.net!news.umass.edu!nic.umass.edu!twain.ucs.umass.edu!mwarchut@network.
  288. Subject: TAPR FTP SITE???
  289. To: ham-digital@ucsd.edu
  290.  
  291. Does anyone know the ftp site for TAPR.
  292.  
  293.  
  294.  
  295. --
  296. *---------------------------------------------------*
  297. |  Michael W. Warchut         Voice:  413-545-2036  |
  298. |  Senior Technician          Fax  :  413-545-2418  |
  299. |  PC Maintenance Lab         I am only 100% right, |
  300. |  University of Mass           50% of the time.    |
  301. *---------------------------------------------------*
  302.  
  303. ------------------------------
  304.  
  305. Date: Sun, 14 Aug 1994 07:15:06 GMT
  306. From: ihnp4.ucsd.edu!agate!library.ucla.edu!news.ucdavis.edu!news!schenck@network.ucsd.edu
  307. Subject: Widrow-Hoff LMS algorithm for DSP???
  308. To: ham-digital@ucsd.edu
  309.  
  310. In article <ahall-1308940337410001@ruger-5.slip.uiuc.edu> ahall@ux4.cso.uiuc.edu (Allen Hall) writes:
  311.  
  312.    Hello again everyone,
  313.  
  314.    I was wondering if you knew anything about the Widrow-Hoff LMS algorithm
  315.    that was used in Sept. 1992 QST's article "Low-Cost Digital Signal
  316.    Processing for the Radio Amateur".  Appearantly the LMS algorithm is nice
  317.    to use to cut out signals that are repetetive when listening to SSB (you
  318.    wouldn't use it for CW- cause all you would hear instead of the morse code
  319.    was a "click" evertime a new tone came buy :)
  320.  
  321.    Appearantly this algorithm is used in the HumVee's to stop engine noise in
  322.    the cabin.  (I think there are other car companies working with it to
  323.    reduce second-order boom in 4 cylinder cars).
  324.  
  325.    If you know where I can find this algorithm or further information about
  326.    it, please let me know.
  327.  
  328.    TNX et 73!
  329.    Allen Hall     n9rzc@uiuc.edu
  330.  
  331.    ps- as always, I look forward to any and all comments that you may have
  332.    concerning this posting.
  333.  
  334.  
  335. Details of the LMS algorithm can be found in virtually any
  336. introductory book or paper on adaptive signal processing, e.g.,
  337. _Adaptive Signal Processing_ by Widrow and Stearns or _Adaptive Filter
  338. Theory_ (or something like that) by Simon Haykin.  The basic algorithm
  339. is as follows:
  340.  
  341. X(k) is an N-element array of input samples at time k.  For a
  342.      transversal filter, the elements of X are samples in a shift
  343.      register.
  344. W(k) is an N-element weight vector (i.e., the filter coefficients)
  345.      at time k.  Ideally, when the adaptive filter converges, W() will
  346.      change slowly or not at all with time.
  347. d(k) is the desired signal at time k.  How this desired signal is
  348.      generated depends on the application.  It can be merely
  349.      correlated with the actual signal.
  350.  
  351. We define the instantaneous error as e(k) = d(k) - X(k)^T W(k), where
  352. ^T denotes matrix transpose.
  353.  
  354. LMS is a form of the steepest descent algorithm dating back to Cauchy
  355. (or some other famous dead guy), where the gradient of the mean
  356. squared error (MSE) with respect to the weight vector is used adjust
  357. the weights so as to minimize the MSE.
  358.  
  359. The trick behind the LMS algorithm is to replace the MSE with the
  360. instantaneous squared error in the computation of the gradient.
  361. Skipping the math (which is actually fairly simple), we get
  362.  
  363. W(k+1) = W(k) + mu e(k) X(k)
  364.  
  365. Simple as that.  mu is called the adaptation step size.  If it is much
  366. too large, the filter becomes unstable and never converges.  If it is
  367. a bit too large, the MSE will not reach its minimum value.  If it is
  368. too small, the filter will take forever and a day to converge.  A
  369. rough first guess for setting mu for a transversal filter is
  370.  
  371. mu = 1 / (N * signal power).
  372.  
  373. Ideally, it should be relatively large at first and then made smaller
  374. when the filter nears convergence.
  375.  
  376. As you can see, it's a simple algorithm to implement, which is why
  377. it's so popular.  It can be slow to converge, however, depending on
  378. the error surface and the initial weight vector.  Also, because it
  379. never (or almost never) actually reaches the minimum MSE, the LMS name
  380. is not quite acurate; some people prefer "stochastic gradient"
  381. algorithm.  But since it's so simple, it's easy to simulate and play
  382. around with on a computer.  Have fun.
  383.  
  384. --
  385. Jeff Schenck
  386. schenck@ece.ucdavis.edu
  387. Department of Electrical and Computer Engineering         __o   
  388. University of California                                _`\<,_  
  389. Davis, CA 95616                                        (_)/ (_) 
  390. (916) 752-1326                                   ~~~~~~~~~~~~~~~
  391.  
  392. ------------------------------
  393.  
  394. Date: 13 Aug 1994 13:15:57 -0700
  395. From: nntp.crl.com!crl3.crl.com!not-for-mail@decwrl.dec.com
  396. Subject: Widrow-Hoff LMS algorithm for DSP???
  397. To: ham-digital@ucsd.edu
  398.  
  399. Allen Hall (ahall@ux4.cso.uiuc.edu) wrote:
  400. : Hello again everyone,
  401.  
  402. : I was wondering if you knew anything about the Widrow-Hoff LMS algorithm
  403. : that was used in Sept. 1992 QST's article "Low-Cost Digital Signal
  404. : Processing for the Radio Amateur".  Appearantly the LMS algorithm is nice
  405. : to use to cut out signals that are repetetive when listening to SSB (you
  406. : wouldn't use it for CW- cause all you would hear instead of the morse code
  407. : was a "click" evertime a new tone came buy :)
  408. : ... etc ...
  409.  
  410.  
  411. The Widrow LMS and  Wiener-Hopf are adaptive digital filtering techniques.
  412.  
  413. The following books have chapters on adaptive digital filters:
  414.  
  415. 1.  Digital Signal Processing - A practical Approach
  416.     Emmanuel C. Ifeachor and Barrie W. Jervis
  417.  
  418. 2.  The TI Digital Signal Processing Applications Series:
  419.     Applications with the TMS320 family, algorithms and implementation
  420.     Vol 1 part number is SPRA012A
  421.     Vol 2 part number is SPRA016
  422.     Vol 3 part number is SPRA017
  423.  
  424.     This series of books deal exclusivly with the TI DSP processors.  There
  425.     is a lot of practical applications as well as some theory.
  426.  
  427.     The TI literature number is 1-800-477-8924, all they need is the part
  428.     numbers and your address, the books are free.
  429.  
  430. --
  431. Henry Smith (hbs@crl.com)
  432.  
  433. ------------------------------
  434.  
  435. Date: Sun, 14 Aug 1994 01:53:33 GMT
  436. From: agate!spool.mu.edu!uwm.edu!news.alpha.net!mvb.saic.com!eskimo!rdonnell@ames.arpa
  437. Subject: Windows 3.1 and Baycom Modem TCP/IP networking
  438. To: ham-digital@ucsd.edu
  439.  
  440. Andrew J Lynch (ei938@cleveland.Freenet.Edu) wrote:
  441.  
  442. : Packet Radio Folks,
  443.  
  444. : I have a question regarding Windows 3.1 or WFW and ham/packet radio:  Is
  445. there a Windows or WFW driver available for the Baycom packt radio modem
  446. that would allow TCP/IP networking functions over packet radio?
  447. : I understand that Windows 3.1 or WFW can use TCP/IP networking with the
  448. WINSOCK.DLL.  This provides TCP/IP networking services to an Windows TCP/IP
  449. application.  Whatever networking medium used requires a driver, ie
  450. SLIP/PPP, ethernet, token ring, etc.
  451. : Ham/packet radio also uses TCP/IP as a protocol in local area networks.  I
  452. have a Baycom modem and plan to use the AX.25 driver withthe DOS program
  453. KA9Q NOS to access the local TCP/IP packet network.
  454.  
  455. : My question is: Is there a way to tie the Baycom modem into Windows 3.1 or
  456. WFW?  You could then use the TCP/IP applications over pacet radio just like
  457. you would over an ethernet or SLIP/PPP, only much slower. I think you would
  458. need a packet driver like the etherne cards require.
  459.  
  460. : Has anyone got any information on this?  If I get any responses, I will
  461. combine and post to this list.
  462.  
  463. : THANKS IN ADVANCE!!
  464.  
  465. : Andrew Lynch, N8VEM
  466. : alynch@wpgate1.wpafb.af.mil
  467.  
  468. : 73!!
  469.  
  470. You're probably not going to have a lot of luck doing this with Windows and
  471. the Baycom.  The Baycom product requires a lot of the computer's attention,
  472. because it has to 'bit-bang' data into and out of the serial port.  It can't
  473. take advantage of the parallel-to-serial/serial-to-parallel conversion
  474. capabilities of the serial port, and therefor is very processor-intensive. 
  475. This along with Windows being intensive and trying to multi-task is not a
  476. good combination.  There are folks who are working on writing a packet
  477. driver to go between Windows TCP/IP applications (Winsock or FTP's PACKET
  478. driver interface) and a KISS-capable TNC.  But I don't think you're going to
  479. see it for Baycom-type modems.
  480.  
  481. Think of it this way - Most Windows systems have trouble keeping up with
  482. 19200 baud with only one task open when you don't use a buffered UART.  All
  483. the application has to do is get the interupt, read the port, clear the
  484. port, then display (or process) the byte received.  At 19200 baud this
  485. happens at 1920 times per second or slower, and you have until the next
  486. charachter has arrived to read the currently stored character before you
  487. will lose data.  Also, typically the most intensive processing that has to
  488. be done on a character-by-character basis is CRC calculations.  When sending
  489. characters, all the program has to do is respond to keyboard interupts (if
  490. typing), send bytes to the com port, and wait for an interupt from the com
  491. port that says it's ready for another byte, and perhaps update CRC
  492. calculation. 
  493.  
  494. With Baycom, assuming the software is set up to use one of the PC's timers
  495. (the lowest processor overhead), at 1200 bauds, when the interupt comes in,
  496. you have to go read the timer, reset the timer, decide how many bit times
  497. have passed since the last interupt, stuff and shuffle the proper number of
  498. bits into the shift register, account for 'bit stuffing', then see if you've
  499. filled a byte.  If so, the byte goes into the packet buffer, and if you have
  500. time, maybe you update the CRC calculation for the packet.  This can happen
  501. in one bit-time (1/1200th of a second, more or less, depending on signal
  502. 'twist' and modem timing errors).  And all that processing has to be
  503. finished before the next interupt.  Then when a packet is complete and
  504. error-free, the driver still has to check addressing, etc.  all of this is
  505. >before< the packet gets passed up to the TCP/IP software stack.  And the
  506. driver has to continue handling interupts and dealing with the incoming data
  507. stream, trying to make sense of it accurately, until the data stream stops -
  508. usually when the squelch on the radio closes.  And during all this, Windows
  509. is supposed to find time for other applications to run.  Not a problem that
  510. will be easily solved.
  511.  
  512. 73,
  513.  
  514. Bob
  515.  
  516. --
  517. ---------------------------------------------------------------------------
  518. Bob Donnell, kd7nm     bob@ethanac.kd7nm.ampr.org   rdonnell@eskimo.com
  519. Western Washington Amateur IP Address Coordinator   (206) 775-3651
  520. ---------------------------------------------------------------------------
  521.  
  522. ------------------------------
  523.  
  524. End of Ham-Digital Digest V94 #272
  525. ******************************
  526.